With the widespread deployment of the global communications network referred to as the Internet, the utilization of e-services has become prevalent. E-services are created in the form of portals and e-business websites. E-service providers interact among themselves to extend a range of functionalities to clients. The interaction may take the form of a static composition in which trading partners are generally fixed, but the trend is toward dynamic composition in which e-service providers dynamically choose their trading partners. As one example, an e-service provider of travel services may interact with a number of alternative e-service providers of airline reservations.
An “e-service” is an on-line service that completes tasks, solves problems, or conducts transactions. E-services are accessible on the Internet at a particular Uniform Resource Locator (URL). An e-service provider may depend upon other e-service providers, with the cooperation being either static or dynamic in nature, as previously noted. In FIG. 1, a parent e-service provider 10 may undertake separate conversations 12 and 14 with two other e-service providers 16 and 18. Provider 10 may be an on-line travel service, while the providers 16 and 18 may be airline and hotel services. The provider 16 is shown as engaging in separate conversations 20 and 22 with a pair of sub e-service providers 24 and 26. The sub providers may be competitors in a car service business. Thus, the e-service provider 16 may subcontract related services.
The e-service providers are federated in nature, since they interact across management domains and enterprise networks. The implementations of the e-services may be vastly different and may be based upon any of a number of different platforms. The diversity in their implementations is one reason why it is difficult to manage the overall process.
In order for the e-service providers 10, 16, 18, 24 and 26 to undertake the conversations 12, 14, 20 and 22, there must be an agreed upon document-exchange protocol or protocols. Standardized protocols include CBL, cXML, and EDI. Each conversation consists of multiple exchanges of documents, such as Extensible Markup Language (XML) documents. Each transmission of an XML document is referred to as an “exchange,” so that a conversation will consist of multiple XML document exchanges. In its simplest form, a conversation consists of an attempt to enter one transaction, but a conversation can result in multiple transactions or may result in no transaction.
Management of e-service conversations is a challenging task because of the varied, federated, decentralized and distributed nature of e-services. As a single transaction spans multiple e-service providers, it is difficult to implement end-to-end e-service management. Nevertheless, there are motivations for enabling the end-to-end management. Such motivations arise from the perspective of both clients and e-service providers. Clients are interested in tracking their interactions and in understanding the internal e-service process flow. An end-to-end understanding enables the client to seek some insight into the actual e-service flow. Service providers that are using other services to provide composite services, such as the providers 10 and 16 in FIG. 1, would benefit from recognizing how the component service providers are behaving. By understanding and observing the behaviors of sub e-services, a composite e-service would be able to optimize itself by either changing its component sub providers or by instructing the existing component sub providers to improve performance.
Referring now to FIG. 2, a typical e-service receives an http request 28 from the parent e-service 10 (if it is not itself the root service) or from an ultimate consumer at a client device, such as a personal computer. The request is routed from one of the web servers 30 in a web server farm 32 to one of the application modules 34 in an application server farm 36. Thereafter, a module 38 of the e-service business logic 40 is applied to the request and a new request 42 is generated for transmission to at least one sub e-service 24. The request 42 is an http request. Some action is performed at the e-service 24 as a response to the request 42. The e-service 24 then generates a response 44 that is expected by a “listener” 46 attached to the web server farm 32.
After the http response 44 is received from the sub e-service 24, the response is directed to the business logic 40, which generates a second http response 48 that is transmitted to the parent e-service 10. The business logic 40 represents the day-to-day operations that are based upon the resources, capabilities and business rules of the particular e-service 16.
The communication pattern among the three e-services 10, 16 and 24 can vary depending upon the implementation. For example, the application logic at the application server farm 36 can cause an immediate response to be sent to the parent e-service 10, before receiving the response 44 from the sub e-service 24. A final response 48 may then be sent at a later time. Also, the final response can be sent directly to the parent e-service 10 from the sub e-service 24, instead of being routed through the business logic 40 of the intermediate e-service 16. In addition, the format of communication is not “symmetric” in the e-services world. That is, an e-service request may not always have a matching response or a single e-service request may have multiple responses. All of these factors add to the difficulty in monitoring and managing end-to-end e-service transactions. Since there is no single point of control, it is difficult to monitor the requests 28 and 42 and the responses 44 and 48 going into and coming from an e-service and to correlate the documents without knowing the business logic of the e-service. Therefore, e-service conversation and transaction level correlation typically requires intrusive instrumentation.
U.S. Pat. No. 6,108,700 to Maccabee et al. describes a method and program storage device for correlating and collating selected measurement events into transactions that describe the behavior of end-to-end business transactions. The end-to-end business transactions are represented by all of the processing stages, such as the requests and responses, that comprise the business transaction. The Maccabee et al. method measures these processing stages and the communications between them by using sensors. The sensors monitor for selected changes in state using a variety of methods to glean which activities are being achieved. Examples of sensors include (1) software written to interact with software exits by registering for notification of selected conditions, (2) software and/or hardware written to intercept activities taken by the business transaction's software and/or hardware (e.g., interception DLLs or shared libraries, or analysis of output logs or alert messages), and (3) insertion of software and/or hardware probes within the business transaction's software and/or hardware (e.g., Application Response Measurement Application Programming Interface (ARM API) calls within business transaction source code). When appropriate, a sensor generates an event that describes the change in state, when and where it has occurred, and any extra data necessary to uniquely identify the event. The events include any additional correlation data useful for later associating the event with other events to form transactions. The sensors forward the events that they generate to their agents for temporary storage, and in certain cases distribution to other system components that have registered interest in knowing that a particular event has occurred.
While the Maccabee et al. method provides significant insights to the end-to-end business transaction processing, what is needed is a more distributed correlation approach that enables end-to-end correlation of e-service transactions in a decentralized manner.